Создание модели данных
Для разработки модели данных использовалось инструментальное средство Erwin. Логический уровень — это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне — сущности и атрибуты. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Логический уровень модели… Читать ещё >
Создание модели данных (реферат, курсовая, диплом, контрольная)
Для разработки модели данных использовалось инструментальное средство Erwin. Логический уровень — это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире. Объекты модели, представляемые на логическом уровне — сущности и атрибуты. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Логический уровень модели данных представлен на рисунке 6.
Рисунок 6. Логический уровень представления Логический уровень отличается от физического тем, что на нем данные выглядят как в реальности. Между тем физический уровень зависит от конкретной СУБД (MS SQL Server 2000), фактически являясь отображением системного каталога. Создав логическую модель, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. В физической модели содержится информация о всех объектах БД.
По заданию на курсовое проектирование нам необходимо использовать нотацию IDEF1X.
Рисунок 7. Физический уровень представления По глубине представления данных модель представляет наиболее детальное представление структуры данных: данные в третьей нормальной форме и включает все сущности, атрибуты и связи, т. е. разработана полная атрибутивная модель системы торгово-закупочной фирмы. На физическом уровне сущности соответствует таблица, экземпляру сущности — строка в таблице, а атрибуту — колонка таблицы. При построении модели данных я определил сущности и атрибуты, а также определил какая информация будет храниться в них, задал связи между сущностями. Хотя в IDEF1X и различают зависимые и независимые сущности, в моей модели использовались только зависимые связи, приводящие к возникновению дочерних и родительских сущностей с миграцией атрибутов. Для однозначного идентифицирования экземпляров сущности были выбраны первичные ключи и альтернативные ключи, не ставшие первичными. Типы данных физической модели однозначно соответствуют типам данных СУБД.
Для того, чтобы удостовериться, что каждый атрибут определен для своей сущности, сократить объем памяти для хранения информации и устранить аномалии необходимо нашу модель данных нормализовать.