База данных для информационной системы «Домашние животные»
В программах, регулирующих ввод информации в базу, необходимо предусмотреть как можно более развернутый и всесторонний контроль вводимых данных, поскольку ошибки в обрабатывающих программах не так опасны, как ошибки в данных, попавшие в базу. Сообщение об ошибках должны быть сформулированы конкретно и однозначно, что позволило бы пользователю предпринять соответственно конкретные и однозначные… Читать ещё >
База данных для информационной системы «Домашние животные» (реферат, курсовая, диплом, контрольная)
1. Модели данных
1.1 Концептуальные модели данных
1.2 Реляционная модель данных
2. Роль баз данных в информационных системах
3. Определение предметной области. Построение модели базы данных для информационной системы «Домашние животные»
Заключение
Список литературы
Введение
База данных есть совокупность данных, организованных в соответствии с некоторой концептуальной моделью данных, которая описывает характеристики этих данных и взаимоотношения между соответствующими им реалиями, и которая предназначена для информационного обеспечения одного или более приложения.
Термин «модель данных» ввел в обращение Эдгар Кодд. Кристофер Дейт в работе «Анализ вклада Кодда в Великий Спор» утверждает, что «Кодд был первым человеком, который попытался дать формальное определение не только реляционной модели, но также и сетевой модели данных.
Выделить какие-либо существенные признаки, характеризующие ту или иную модель данных весьма непросто. Даже при описании родственных иерархической и сетевой моделей терминология резко отличается. Понятия записи, набора, сегмента, узла, кортежа, объекта, типа и другие иногда используются как синонимы, но нередко даже один и тот же термин используется в разных смыслах. Лучше других формализована реляционная модель данных, однако большинство систем управления базами данных, которые принято называть реляционными, в реальности ее не поддерживают.
В статье «Модели данных в управлении базами данных» Кодд определяет модель данных как комбинацию трех компонентов: коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели; коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов; коллекции операций, применимых к таким экземплярам объектов.
Кристофер Дейт утверждал: «Модель данных есть теория, или средство моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. Соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке» .
Косвенным свидетельством в пользу точности определения Дейта является факт существования так называемых «SQL-серверов» — концепции баз данных, отличающейся от реляционной модели во многих деталях, и содержащих слово «язык» уже в названии (Structured Query Language).
Само понятие «модель данных» появилось для обеспечения возможности сравнения различных подходов к проектированию баз данных.
1. Модели данных
Каждая система управления базами данных поддерживает определенное множество концептуальных моделей, определяя тем самым некоторую модель данных:
Модель данных есть совокупность методов и средств определения логической структуры базы данных и динамического моделирования состояния предметной области в базе данных.
Длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных» он определил модель данных как комбинацию трех компонентов:
1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели;
2. Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов, которые законным образом могут появиться в любой такой базе данных;
3. Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей.
Аспект структуры определяет, что из себя логически представляет база данных, аспект целостности определяет средства описаний корректных состояний базы данных, аспект манипуляции определяет способы перехода между состояниями базы данных (то есть способы модификации данных) и способы извлечения данных из базы данных.
Ближе всего к этой концепции является современный взгляд на понятие о модели данных по М. Р. Когаловскому: «Система типовых данных, типов связей между ними и допустимых видов ограничений целостности, которые могут быть для них определены».
Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных.
Каждая база данных и система управления базами данных строится на основе некоторой явной или неявной модели данных. Все системы управления базами данных, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных систем управления базами данных является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических — иерархическая модель данных и так далее.
Модель данных есть теория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. Соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных.
1.1 Концептуальные модели данных
Концептуальные модели данных. В отличие от инфологической модели предметной области, описывающей по некоторым правилам сведения об объектах материального мира и связи между ними, которые следует иметь в БД, концептуальная модель описывает хранимые в ЭВМ данные и связи. В силу этого каждая модель данных неразрывно связана с языком описания данных конкретной СУБД .
По существу модель данных — это совокупность трех составляющих:
— типов (структур) данных;
— операций над данными;
— ограничений целостности.
Другими словами, модель данных представляет собой некоторое интеллектуальное средство проектировщика, позволяющее реализовать интерпретацию сведений о ПО в виде формализованных данных в соответствии с определенными требованиями, то есть средство абстракции, которое дает возможность увидеть «лес» (информационное содержание данных), а не отдельные «деревья» (конкретные значения данных).
Типы структур данных. Среди широкого множества определений, обозначающих типы структур данных, наиболее распространена терминология КОДАСИЛ (Conference of DAta SYstems Language) Международной ассоциации по языкам систем обработки данных, созданной в 1959 г.
В соответствии с этой терминологией используют пять типовых структур (в порядке усложнения): элемент данных, агрегат данных, запись, набор, база данных.
База данных — поименованная совокупность экземпляров записей различного типа, содержащая ссылки между записями, представленные экземплярами наборов.
Отметим, что структуры БД строятся на основании следующих основных композиционных правил:
— БД может содержать любое количество типов записей и типов наборов;
— между двумя типами записей может быть определено любое
количество наборов;
— тип записи может быть владельцем и одновременно членом
нескольких типов наборов.
Следование данным правилам позволяет моделировать данные о сколь угодно сложной ПО с требуемым уровнем полноты и детализации.
Рассмотренные типы структур данных могут быть представлены в различной форме — графовой, табличной, в виде исходного текста языка описания данных конкретной СУБД.
Операции над данными. Операции, реализуемые СУБД, включают селекцию (поиск) данных, а также действия над данными.
Селекция данных выполняется с помощью критерия, основанного на использовании либо логической позиции данного (элемента, агрегата, записи), либо значения данного, либо связей между данными.
Селекция на основе логической позиции данного базируется на упорядоченности данных в памяти системы. При этом критерии поиска могут формулироваться следующим образом:
— найти следующее данное (запись);
— найти предыдущее данное;
— найти n-ое данное;
— найти первое (последнее) данное.
Этот тип селекции называют селекцией посредством текущей, в качестве которой используется индикатор текущего состояния, автоматически поддерживаемый СУБД и, как правило, указывающий на некоторый экземпляр записи БД.
Критерий селекции по значениям данных формируется из простых или булевых условий отбора. Примерами простых условий поиска являются
— ВУС = 200 100;
— ВОЗРАСТ > 20;
— ДАТА < 19.04.2002 и так далее.
Булево условие отбора формируется путем объединения простых условий с применением логических операций, например
— (ДАТА_РОЖДЕНИЯ < 28.12.1963) И (СТАЖ > 10);
— (УЧЕНОЕ_ЗВАНИЕ — ДОЦЕНТ) ИЛИ (УЧЕНОЕ ЗВАНИЕ = ПРОФЕССОР) и так далее.
Если модель данных, поддерживаемая некоторой СУБД, позволяет выполнить селекцию данных по связям, то можно найти данные, связанные с текущим значением какого-либо данного. Например, если в модели данных реализована двунаправленная связь «учится» между сущностями «студент» и «учебная группа», то можно выявить учебные группы, в которых учатся юноши (если в состав описания «студент» входит атрибут «пол»).
Как правило, большинство современных СУБД позволяют осуществлять различные комбинации описанных выше видов селекции данных.
Ограничения целостности. Ограничения целостности — логические ограничения на данные, которые используются для обеспечения непротиворечивости данных некоторым заранее заданным условиям при выполнении операций над ними. По сути, ограничения целостности — это набор правил, используемых при создании конкретной модели данных на базе выбранной СУБД.
Различают внутренние и явные ограничения.
Ограничения, обусловленные возможностями конкретной СУБД, называют внутренними ограничениями целостности.
Эти ограничения касаются типов хранимых данных (например, «текстовый элемент данных может состоять не более чем из 256 символов» или «запись может содержать не более 100 полей») и допустимых типов связей (например, СУБД может поддерживать только функциональные связи, т. е. связи типа 1: 1, 1: Мили М: 1). Большинство существующих СУБД поддерживают прежде всего именно внутренние ограничения целостности, нарушения которых приводят к некорректности данных и достаточно легко контролируются.
Ограничения, обусловленные особенностями хранимых данных о конкретной ПО, называют явными ограничениями целостности.
Данные ограничения также поддерживаются средствами выбранной СУБД, но они формируются обязательно с участием разработчика БД путем определения (программирования) специальных процедур, обеспечивающих непротиворечивость данных. Ключ должен быть уникальным, то есть в БД не должно быть двух записей с одинаковыми значениями ключа. Например: пусть в записи предусмотрен элемент «военно-учетная специальность» и для него отведено 6 цифр, тогда другие представления этого элемента данных в БД невозможны. С помощью явных ограничений целостности можно организовать «простой» контроль вводимых данных прежде всего, на предмет принадлежности элементов данных фиксированному и заранее заданному множеству значений.
Элементарная единица данных может быть реализована множеством способов, что, в частности, привело к многообразию известных моделей данных. Модель данных определяет правила, в соответствии с которыми структурируются данные. Обычно операции над данными соотносятся с их структурой.
Разнообразие существующих моделей данных соответствует разнообразию областей применения и предпочтений пользователей.
В специальной литературе встречается описание довольно большого количества различных моделей данных. Хотя наибольшее распространение получили иерархическая, сетевая и, бесспорно, реляционная модели, вместе с ними следует упомянуть и некоторые другие.
Используя в качестве классификационного признака особенности логической организации данных, можно привести следующий перечень известных моделей:
— иерархическая модель данных;
— сетевая модель данных;
— реляционная модель данных;
— бинарная модель данных;
— семантическая сеть;
Рассмотрим основные особенности перечисленных моделей.
Иерархическая модель данных. Наиболее давно используемой (можно сказать, классической) является модель данных, в основе которой лежит иерархическая структура типа дерева. Дерево — это орграф, в каждую вершину которого, кроме первой (корневой), входит только одна дуга, а из любой вершины (кроме конечных) может исходить произвольное число дуг. В иерархической структуре подчиненный элемент данных всегда связан только с одним исходным.
Достоинства такой модели несомненны: простота представления предметной области, наглядность, удобство анализа структур и простота их описания. К недостаткам следует отнести сложность добавления новых и удаления существующих типов записей, невозможность отображения отношений, отличающихся от иерархических, громоздкость описания и информационную избыточность.
Характерные примеры реализации иерархических структур — язык Кобол и СУБД семейства IMS (создана в рамках проекта высадки на Луну — «Аполлон») и System 2000 (S2K).
Сетевая модель данных. В системе баз данных, предложенных CODASYL, за основу была взята сетевая структура. Существенное влияние на разработку этой модели оказали более ранние сетевые системы — IDS и Ассоциативный ПЛ/1. Необходимость в процессе получения одного отчета обрабатывать несколько файлов обусловила целесообразность установления перекрестных ссылок между файлами, что в конце концов и привело к сетевым структурам .
Сетевая модель данных основана на представлении информации в виде орграфа, в котором в каждую вершину может входить произвольное число дуг. Вершинам графа сопоставлены типы записей, дугам — связи между ними.
По сравнению с иерархическими сетевые модели обладают рядом существенных преимуществ: возможность отображения практически всего многообразия взаимоотношений объектов предметной области, непосредственный доступ к любой вершине сети (без указания других вершин), малая информационная избыточность. Вместе с тем, в сетевой модели невозможно достичь полной независимости данных — с ростом объема информации сетевая структура становится весьма сложной для описания и анализа.
Известно, что применение на практике иерархических и сетевых моделей данных в некоторых случаях требует разработки и сопровождения значительного объема кода приложения, что иногда может стать для информационной системы непосильным бременем
Реляционная модель данных. В основе реляционной модели данных лежат не графические, а табличные методы и средства представления данных и манипулирования ими. В реляционной модели для отображения информации о предметной области используется таблица, называемая «отношением». Строка такой таблицы называется кортежем, столбец — атрибутом. Каждый атрибут может принимать некоторое подмножество значений из определенной области — домена.
Табличная организация БД позволяет реализовать ее важнейшее преимущество перед другими моделями данных, а именно — возможность использования точных математических методов манипулирования данными, и, прежде всего, аппарата реляционной алгебры и исчисления отношений. К другим достоинствам реляционной модели можно отнести наглядность, простоту изменения данных и организации разграничения доступа к ним.
Основным недостатком реляционной модели данных является информационная избыточность, что ведет к перерасходу ресурсов вычислительных систем. Однако именно реляционная модель данных находит все более широкое применение в практике автоматизации информационного обеспечения профессиональной деятельности.
Подавляющее большинство СУБД, ориентированных на персональные ЭВМ, являются системами, построенными на основе реляционной модели данных, так называемыми «реляционными» СУБД.
Бинарная модель данных. Бинарная модель данных — это графовая модель, в которой вершины являются представлениями простых однозначных атрибутов, а дуги — представлениями бинарных связей между атрибутами.
Бинарная модель не получила особо широкого распространения, но в ряде случаев находит практическое применение.
Так, в области искусственного интеллекта уже давно ведутся исследования с целью представления информации в виде бинарных отношений. Рассмотрим триаду (тройку) «объект — атрибут — значение». Триада «Кузнецов — возраст — 20» означает, что возраст некоего Кузнецова равен 20 годам. Эта же информация может быть выражена, например, бинарным отношением ВОЗРАСТ. Понятие бинарного отношения положено в основу таких моделей данных, как, например, Data Semantics (автор — Абриал) и DIAM II (автор — Сенко).
Бинарные модели данных обладают возможностью представления связей любой сложности (и это их несомненное преимущество), но, вместе с тем, их ориентация на пользователя недостаточна.
Семантическая сеть. Семантические сети как модели данных были предложены исследователями, работавшими над различными проблемами искусственного интеллекта. Так же, как в сетевой и бинарной моделях, базовые структуры семантической сети могут быть представлены графом, множество вершин и дуг которого образует сеть. Однако семантические сети предназначены для представления систематизации знаний самого общего характера.
Таким образом, семантической сетью можно считать любую графовую модель (например, помеченный бинарный граф), при условии, что изначально четко определено, что обозначают вершины и дуги и как они используются.
Семантические сети являются богатым источником идей моделирования данных, чрезвычайно полезным в плане решения проблемы представления сложных ситуаций. Они могут быть использованы независимо или совместно с идеями, положенными в основу других моделей данных. Их интересной особенностью является то, что расстояние, измеренное на сети (семантическое расстояние, или метрика), играет важную роль, определяя близость взаимосвязанных понятий. При этом предусмотрена возможность в явной форме подчеркнуть, что семантическое расстояние велико.
Следует сказать, что моделям данных типа семантической сети при всем присущем им богатстве возможностей при моделировании сложных ситуаций присуща усложненность и некоторая неэкономичность в концептуальном плане.
1.2 Реляционная модель данных
Реляционная модель данных. В основе реляционной модели данных лежит их представление в виде таблиц, что в значительной степени облегчает работу проектировщика БД, а в последующем и пользователя в силу привычности и распространенности такого варианта использования информации. Данная модель была предложена Э. Ф. Коддом (Е. F. Codd) в начале 70-х годов и вместе с иерархической и сетевой моделями составляет множество так называемых великих моделей. Можно сказать, что сегодня именно эта модель используется во всех наиболее распространенных СУБД.
Определение любой модели данных требует описания трех элементов, в частности определение:
— типов (структур) данных;
— операций над данными;
— ограничений целостности.
Сначала рассмотрим структуры данных и ограничения целостности, затем более подробно остановимся на операциях реляционной алгебры.
Типы структур данных. Рассмотрение этого вопроса требует введения определений нескольких основных понятий.
Множество возможных значений некоторой характеристики объекта называется доменом (domain):
A ={dn, di2, din}
Например, в качестве домена можно рассматривать такие характеристики студента, как его фамилия, курс, рост и т. п.:
DKypc={l, 2, 3, 4, 5};
Dфамилия ={Иванов, Петров, Сидоров,…};
Dрост = {160, 161, 162, …, 190}.
Очевидно, что можно сопоставить понятия «атрибут» инфологической и «домен» реляционной моделей данных. Возможные значения характеристик объектов могут принимать числовые или текстовые значения, а их множества могут быть как конечными, так и бесконечными. Отметим, что в случае конечности домена можно организовать проверку явных ограничений целостности: в нашем примере домен Dрocт определяет, что все студенты должны иметь рост от 160 до 190 см, а номер курса не может превышать 5.
Вектор размерности к, включающий в себя по одному из возможных значений к доменов, называется кортежем (tuple).
Если в кортеж входят значения всех характеристик объекта ПО (т.е. атрибутов сущности инфологической модели), ему можно сопоставить такую типовую структуру данных, как запись (объектная запись).
Декартовым произведением к доменов называется множество всех возможных значений кортежей:
D = D1xD2x…xDk.
При увеличении размерности любого из доменов увеличивается и верность их декартова произведения.
Иными словами, декартово произведение — множество всех возможных комбинаций элементов исходных доменов. Наконец, важнейшее определение: отношением (relation) R, определенным на множествах доменов D1, D2,…, Dk, называют подмножество их декартова произведения:
R D1xD2x…xDk.
Элементами отношения являются кортежи. Отношение может моделировать множество однотипных объектов (сущностей), причем экземпляр сущности может интерпретироваться, как кортеж. С помощью отношения можно моделировать и связи, в которых находятся объекты ПО.
Таким образом, понятие отношения позволяет моделировать данные и связи между ними. В силу этого можно определить реляционную базу данных (РБД) как совокупность экземпляров конечных отношений.
Любой запрос в такой системе может быть представлен в виде формулы, состоящей из отношений, объединенных операциями реляционной алгебры. Создав СУБД, обеспечивающую выполнение этих операций, можно разрабатывать информационные системы, в которых любой запрос потребителя программируется формулой.
Ограничения целостности. Отношение может быть представлено таблицей, обладающей определенными свойствами (которые, по сути, и определяют внутренние ограничения целостности данных):
— каждая строка таблицы — кортеж;
— порядок строк может быть любым;
— повторение строк не допускается;
— порядок столбцов в отношении фиксирован.
Понятие «отношение» весьма схоже с понятием «файл данных». В дальнейшем будем использовать следующую терминологию: отношение — файл, кортеж — запись, домен — поле. Идентификация конкретной записи файла осуществляется по ключу (набору полей, по значению которого можно однозначно идентифицировать запись). В файле можно определить несколько ключей. Один из них, включающий минимально возможное для идентификации записи число полей, называется первичным ключом.
Применительно к понятию «файл данных» внутренние ограничения целостности формулируются следующим образом:
— количество полей и их порядок в файле должно быть фиксированным (т.е. записи файла должны иметь одинаковые длину и формат);
— каждое поле должно моделировать элемент данных (неделимую единицу данных фиксированного формата, к которому СУБД может адресоваться непосредственно);
— в файле не должно быть повторяющихся записей.
СУБД, основанные на РБД, поддерживают и явные ограничения целостности. На практике они определяются зависимостями между атрибутами.
информационный модель база данные
2. Роль баз данных в информационных системах
Новые подходы к манипулированию информацией открывают перспективы качественно иного использования постоянно возрастающего объема документальных источников информации. Принципиальной особенностью гипермедиа является распространение идеи гипертекста, то есть ассоциативно связанной текстовой информации, на видеои аудиоинформацию, хранящуюся в цифровой форме.
Системы гипермедиа, как и гипертекстовые, могут рассматриваться в разных аспектах. Один из подходов заключается в том, чтобы сравнивать методы доступа к информации в гипертексте с соответствующими методами в системах управления базами данных. Эти методы различны: в гипертексте они опираются на ассоциативные связи между понятиями, в системах управления базами данных — на структуры данных. Между системами гипертекста и гипермедиа нет четкой границы. Если Guide является чисто гипертекстовой системой, то Hypercard, ArchiText включают элементы гипермедиа. Такие системы, как Intermedia, NLS/Ogment, NoteCard, Xanadu представляют собой этапное достижение в развитии информационной технологии, ориентированной в первую очередь на обработку знаний.
В настоящее время ведены базовые объектные модели, унифицированные языки спецификации интерфейсов объектов. Тем самым достигается однородность представления компонентов и их взаимодействия (на основе идеи «клиент-сервер») в глобальном объектном пространстве, в котором каждый информационный ресурс однородно представляется совокупностью объектов. Далее, для формирования информационной архитектуры вводится слой унифицированных (ортогональных) служб, которые используются при конструировании прикладных систем.
Интересным явлением в современных исследованиях баз данных является широкое участие в них как ученых и исследователей из университетов, академических научно-исследовательских институтов, так и специалистов из научно-исследовательских лабораторий коммерческих компаний-производителей аппаратуры и/или программного обеспечения. Это весьма положительное явление, позволяющее университетам и научно-исследовательским институтам в большей степени оценивать практическую значимость своих исследований и дающее возможность компаниям использовать наиболее свежие достижения теоретиков.
Достаточно условно можно выделить четыре основных исследовательских области, связанных с проблематикой баз данных. Первая область наиболее близка к сегодняшним проблемам индустрии баз данных, основанных на реляционной модели данных. Хотя иногда кажется, что эта область настолько хорошо разработана, что в ней уже не осталось нерешенных проблем, на самом деле это не совсем так. Более того, те вопросы, решение которых еще не найдено, актуальны и для следующих поколений систем баз данных.
3. Определение предметной области. Построение модели базы данных для информационной системы «Домашние животные»
База данных является динамической информационной моделью некоторой предметной области, отображением внешнего мира. Каждому объекту присущ ряд характерных для него свойств, признаков, параметров.
Работа с базами данных осуществляется по атрибутам объектов.
В программах, регулирующих ввод информации в базу, необходимо предусмотреть как можно более развернутый и всесторонний контроль вводимых данных, поскольку ошибки в обрабатывающих программах не так опасны, как ошибки в данных, попавшие в базу. Сообщение об ошибках должны быть сформулированы конкретно и однозначно, что позволило бы пользователю предпринять соответственно конкретные и однозначные действия. Несмотря на большую трудоемкость программирования, такой контроль окажется неоценимым при эксплуатации комплекса программ. Любые изменения, вносимые в базу данных должны протоколироваться.
Рисунок 1. Модель базы данных для информационной системы «Домашние животные»
Рассмотрим свойства каждого поля таблицы «Домашние животные», базы данных для информационной системы «Домашние животные», представленные в Таблице 1.
Таблица 1 Свойства полей таблицы «Домашние животные»
Имя поля | Тип данных | Свойства поля | ||
Общие | Подстановка | |||
Животное | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: список значений; источник строк: «Кошка»; «Собака»; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 1,429 см; число срок списка: 8; ширина списка: 1,429 см; ограничиться списком: нет. | |
Кличка | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: список значений; источник строк: «Гертруда» ;" Маркиза"; «Кармелита» ;" Олимпиада"; «Барс» ;" Черника" ;" Элен"; «Флёр» ;" Барон" ;" Граф" ;" Хард"; «Черри»; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 2,011 см; число срок списка: 8; ширина списка: 2,011 см; ограничиться списком: нет. | |
Порода | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: список значений; источник строк: «Голден ретривер» ;" Леонбергер"; «Маремма» ;" Бладхаунд"; «Ирландский сеттер»; «Американский бульдог»; «Египетская мау»; «Шартриз»; «Японский бобтейл»; «Регдолл»; «Британская короткошерстная кошка»; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 5, 371 см; число срок списка: 8; ширина списка: 5,37 см; ограничиться списком: нет. | |
Пол | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: список значений; источник строк: «М» ;" Ж"; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 0,794 см; число срок списка: 8; ширина списка: 0,794 см; ограничиться списком: да. | |
Год рождения | Дата/время | Формат поля: краткий формат даты; маска ввода: 00.00.0000; обязательное поле: нет; индексированное поле: нет; режим IME: нет контроля; режим предложений IME: нет. | ||
Возраст | Числовой | Размер поля: длинное целое; число десятичных знаков: авто; значение по умолчанию: 0; обязательное поле: нет; индексированное поле: нет | Тип элемента управления: поле | |
Рост | Числовой | Размер поля: длинное целое; число десятичных знаков: авто; значение по умолчанию: 0; обязательное поле: нет; индексированное поле: нет | Тип элемента управления: поле | |
Вес | Числовой | Размер поля: длинное целое; число десятичных знаков: авто; значение по умолчанию: 0; обязательное поле: нет; индексированное поле: нет | Тип элемента управления: поле | |
Окрас | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: список значений; источник строк: «Бронзовый» ;" Черный" ;" Серо-голубой" ;" Голубая табби"; «Серебристо-серый» ;" Красно-белый" ;" Белый" ;" Рыжий" ;" Коричневый" ;" Золотистый" ;" Черно-рыжий"; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 3,122 см; число срок списка: 8; ширина списка: 3,122 см; ограничиться списком: нет. | |
Отец | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: таблица или запрос; источник строк: SELECT Отец. Кличка FROM Отец ORDER BY [Кличка]; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 2,54 см; число срок списка: 8; ширина списка: 2,54 см; ограничиться списком: нет. | |
Мать | Текстовый | Размер поля: 50; обязательное поле: нет; пустые строки: да; индексированное поле: нет; сжатие Юникод: да; режим IME: нет контроля; режим предложений IME: нет. | Тип элемента управления: поле со списком; тип источника строк: таблица или запрос; источник строк: SELECT Мать. Кличка FROM Мать ORDER BY [Кличка]; присоединенный столбец: 1; число столбцов: 1; заглавия столбцов: нет; ширина столбцов: 2,54 см; число срок списка: 8; ширина списка: 2,54 см; ограничиться списком: нет. | |
Рассмотрим результаты создания базы данных для информационной системы «Домашние животные» на основании модели, изображенной на Рисунке 1.
Далее в контрольной работе представлены рисунки, позволяющие визуально рассмотреть несколько таблиц уже созданной базы данных для информационной системы «Домашние животные».
Рисунок 2. Таблица «Домашние животные» в режиме конструктора Рисунок 3. Таблица «Домашние животные» в режиме таблицы Рисунок 4. Таблица «Мать» в режиме конструктора Рисунок 5. Таблица «Мать» в режиме в режиме таблицы Рисунок 6. Таблица «Отец» в режиме конструктора Рисунок 7. Таблица «Отец» в режиме таблицы
Запрос 2: запрос на выборку
SELECT [Домашние животные]. Животное, [Домашние животные]. Кличка, [Домашние животные]. Порода, [Домашние животные]. Возраст, [Домашние животные]. Окрас, [Домашние животные]. Мать
FROM [Домашние животные];
Рисунок 8. Запрос 2 в режиме конструктора Рисунок 9. Результат Запроса 2 в режиме таблицы Результат Запроса 2 в форме Отчета
Заключение
Теоретически упомянутые модели данных, а также большинство неупомянутых равносильны в том смысле, что все, выразимое в одной из них, выразимо в остальных. Различие составляет то, насколько удобно использовать ту или иную модель проектировщику-человеку для работы с реальными жизненными задачами, и то, насколько эффективно можно реализовать работу с конкретной моделью на ЭВМ (если это возможно вообще). Как уже говорилось, однозначно общеупотребимой модели сейчас нет и, по-видимому, не будет никогда, и разные модели сосуществуют. Более того, они существуют взаимосвязано либо же попытки такой взаимоувязки (вплоть до объединения) неустанно предпринимаются.
Программная реализация моделей данных, то есть построение систем управления базами данных или программных систем, наталкивается на большие сложности. Наиболее отчетливо это видно на примере реляционной модели, для которой ни одной системы управления базами данных, если следовать строго определениям, не создано. Вместо этого имеется целое семейство систем, в той или иной степени поддерживающих язык работы с данными SQL. SQL изначально появился как язык для реляционных СУБД, однако по мере своего практического развития он все больше и больше отклонялся от реляционности. Причиной тому являются как принципиальные проблемы реализации, так и организационно-рыночные факторы, не позволяющие разным производителям систем управления базами данных договориться о «правильном» стандарте.
Разработки целевых информационных систем и баз данных, имеют большое значение для развития соответствующих направлений науки. Большинство из этих разработок аналогов не имеет и предоставляет для исследователей и разработчиков существенно новую информацию и способы ее обработки.
Список литературы
1. Арсеньев Ю. Н., Шелобаев С. И., Давыдова Т. Ю. Информационные системы и технологии. Экономика. Управление. Бизнес: Учебное пособие для вузов. - М.: ЮНИТИ-ДАНА, 2006.
2. Бережная Е. В., Бережной В. И. Математические методы моделирования экономических систем. - М.: Финансы и статистика, 2001.
3. Макаров А. С., Лисовский К. Ю. Базы данных.
Введение
в теорию и методологию: Учебник. - М.: Финансы и статистика, 2006.
4. Уткин В. Б., Балдин К. В. Информационные системы и технологии в экономике: Учебник для вузов - М.: ЮНИТИ-ДАНА, 2003.
5. Фомин Г. П. Системы и модели массового обслуживания коммерческой деятельности. - М.: Финансы и статистика, 2000.