Навигация
1 М М 1
В разных нотациях мощность связи изображается по-разному. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной – если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях. Мы снова используем нотацию POWER DESIGNER. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что, по крайней мере, один экземпляр сущности участвует в этой связи.
Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то есть сущность может быть представлена в виде двух или более своих подтипов – сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный перечень подтипов, то вводится специальный подтип, называемый условно «Прочие», который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности – это имя типа, а не конкретного экземпляра.
Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности – сильной по отношению к ней.
Сущность может быть расщеплена на два или более взаимоисключающих подтипов, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе выделение подтипов может продолжаться на более низких уровнях, но в большинстве случаев оказывается достаточно двух-трех уровней.
Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, то есть любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например, «Прочие».
Заключение
На мой взгляд, нелегко правильно воспринять и оценить тех советов и рекомендаций по построению хорошей инфологической модели, которые десятилетиями формировались крупнейшими специалистами в области обработки данных. В идеале необходимо, чтобы предварительно был реализован хотя бы один проект информационной системы, предложенный его реальным пользователям.
Любые теоретические рекомендации воспринимаются всерьез лишь после нескольких безрезультатных попыток оживления неудачно спроектированных систем. (Хотя есть и такие проектировщики, которые продолжают верить, что смогут реанимировать умирающий проект с помощью изменения программ, а не инфологической модели базы данных)
Для определения перечня и структуры хранимых данных надо собрать информацию о реальных и потенциальных приложениях, а также о пользователях базы данных, а при построении инфологической модели следует заботиться лишь о надежности хранения этих данных, напрочь забывая о приложениях и пользователях, для которых создается база данных.
Целесообразно:
четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);
помнить, что, как правило, база данных является информационной основой не одного, а нескольких приложений, часть их которых появится в будущем;
плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.
Список литературы
1. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.
2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.
3. Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.
4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. - М.: Мир, 1991. – 252 с.
5. Кириллов В.В. Структуризованный язык запросов (SQL). – СПб.: ИТМО, 1994. – 80 с.
6. Мартин Дж. Планирование развития автоматизированных систем. – М.: Финансы и статистика, 1984. – 196 с.
7. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.
8. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн.1. – 287 с.: Кн.2. – 320 с.
9. Ульман Дж. Базы данных на Паскале. – М.: Машиностроение, 1990. – 386 с.
10. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984. – 294 с.
11. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 1985. – 344 с.
Похожие работы
... основании данных содержащихся в карточке клиента. - Подпрограмма редактирования таблиц служит для изменения данных в таблицах о стоимости на производство работ и цен на материалы. С помощью этой подпрограммы можно вносить дополнения ко всем базам данных содержащимся в разработке. Алгоритм работы этой подпрограммы показан на рис. 2.4. ...
логическую среду для разработки больших экономических моделей. Система должна работать под управлением Windows95, реализована в среде разработки Borland Delphi 3 и должна состоять из двух компонентов - вычислительного ядра системы (engine) и оболочки над ним. Оболочка включает в себя: · Набор интерфейсов для всех типов процессов · База данных (БД), структура которой предполагает ...
... . Иерархическая организация не может обеспечить быстродействие, необходимое для работы в условиях одновременного модифицирования файлов несколькими прикладными подсистемами. 4.1. Иерархические структуры в реляционных базах данных Окружающий мир переполнен иерархическими данными. В это широкое понятие входят компании, состоящие из дочерних компаний, филиалов, отделов и рабочих групп; детали ...
... к первой фазе и является наиболее трудным и длительным во времени этапом процесса проектирования. Однако он является наиболее важным, т.к. на его базе строится большинство проектных решений. Основной задачей является сбор требований, предъявляемых к содержанию и процессу обработки данных пользователями всех уровней. Анализ требований обеспечивает согласованность целей пользователей, а также ...
0 комментариев