Проектирование баз данных

Основы проектирования аналитических баз данных, определение предметной области, цели и сущности моделирования. Особенности инфологического, даталогического и физического моделирования баз данных. Использование Microsoft Access при обработке информации.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 25.10.2009
Размер файла 923,7 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

2

СОДЕРЖАНИЕ

Введение

1. Аналитическая часть

1.1 Характеристика предметной области

1.2 Инфологическая модель

1.3 Даталогическое проектирование базы данных

1.4 Физическое проектирование базы данных

2. Проектная часть

2.1 Краткая характеристика Microsoft Access

2.2 Создание таблиц

2.3 Создание схемы данных

2.4 Создание форм, запросов и отчетов

Заключение

Список литературы

Введение

Курсовой проект преследует цель оценить уровень подготовки студентов по общепрофессиональным и специальным дисциплинам, полученные ими теоретические знания, приобретенные навыки самостоятельной работы, умение синтезировать полученные знания и применять их к решению практических задач.

Выполнение КП является одним из завершающих и наиболее значимым этапом обучения студентов по дисциплине «Разработка и эксплуатация автоматизированных информационных систем». Его конечным результатом является представление и защита оформленной соответствующим образом работы, в которой отражается содержание изучаемой дисциплины и качество подготовки специалистов этого направления. Конечной целью КП является выявление уровня подготовки студента, степени готовности его к усвоению профессиональных знаний.

Основными задачами выполнения КП является:

1. выявление понимания студентом основных проблем и перспектив развития технологии проектирования автоматизированных информационных систем;

2. выявление понимания студентом значимости своей будущей профессиональной деятельности, умения приобретать новые знания, особенно в области современных информационных технологий;

3. выявление умения работать с технической и нормативной документацией, а также четко излагать свои мысли;

4. выявление навыков решать поставленные практические задачи с использованием теоретических знаний;

Цель нашего проекта - предоставить удобный и быстрый доступ к базе данных, содержащей информацию об адресах. Актуальность информации поддерживается за счет предоставления всем пользователям возможности бесплатно разместить информацию о своей фирме.

1. Аналитическая часть

1.1 Характеристика предметной области

С точки зрения проектирования БД в рамках системного анализа, необходимо осуществить первый этап, то есть провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.

В общем случае существуют два похода к выбору состава и структуры предметной области:

· Функциональный подход - он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая СУБД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

· Предметный подход - когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в некотором смысле кажется гораздо более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.

Чаще всего на практике рекомендуется использовать некоторый компромиссный вариант, который, с одной стороны, ориентирован на конкретные задачи или функциональные потребности пользователей, а с другой стороны, учитывает возможность наращивания новых приложений.

Предметная область - часть реального мира отражённая в базу данных.

Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных.

Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком. Конструктивными основными элементами инфологических моделей являются сущности, связи между ними и их свойства.

Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов - характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.

ГРАФИК открытия и закрытия вестибюлей станций Петербургского метрополитена

№ п/п

Станция

Время открытия

Время закрытия

№ п/п

Станция

Время открытия

Время

закрытия

1.

Проспект Ветеранов-1

6.30

20.00

38.

Черная речка

5.48

0.32

2.

Проспект Ветеранов-2

5.38

0.00

39.

Пионерская

5.45

0.35

3.

Ленинский проспект-1

5.40

0.45

40.

Удельная

5.43

0.38

4.

Ленинский проспект-2

6.30

20.00

41.

Озерки

5.40

0.41

5.

Автово

5.32

0.42

42.

Проспект Просвещения

5.35неч

0.00

6.

Кировский завод

5.34

0.40

5.55чет

7.

Нарвская

5.38

0.36

43.

Приморская

5.35

0.05

8.

Балтийская

5.40

0.33

44.

Василеостровская

5.35

0.34

9.

Пушкинская

5.45

0.28

45.

Гостиный Двор

5.40

0.30

10.

Владимирская

закрыта на ремонт

46.

Маяковская

5.45

0.26

11.

Площадь Восстания-1

5.45

0.26

47.

Площадь Ал.Невского-1

5.40

0.25

12.

Площадь Восстания-2

5.45

0.26

48.

Елизаровская

5.40

0.24

13.

Чернышевская

5.45

0.25

49.

Ломоносовская

5.35

0.27

14.

Площадь Ленина-1

5.40

0.28

50.

Пролетарская

5.40

0.30

15.

Площадь Ленина-2

5.40

22.00

51.

Обухово

5.40

0.33

16.

Выборгская

5.46

0.30

52.

Рыбацкое

5.38

0.05

17.

Лесная

5.44

0.33

53.

Улица Дыбенко

5.35

0.05

18.

Площадь Мужества

5.42

0.37

54.

Проспект Большевиков

5.40

0.36

19.

Политехническая

5.40

0.39

55.

Ладожская

5.40

0.33

20.

Академическая

5.35

0.40

56.

Новочеркасская

5.43

0.31

21.

Гражданский проспект

5.30

0.45

57.

Площадь Ал.Невского-2

7.00

20.00

22.

Девяткино

5.32

0.00

58.

Лиговский проспект

5.45

0.28

23.

Купчино

5.30

0.00

59.

Достоевская

5.43

0.26

24.

Звездная

5.35

0.42

60.

Садовая

5.40

0.22

25.

Московская-1

6.30

22.00

61.

Спортивная

5.40

0.30

26.

Московская-2

5.38

0.38

62.

Чкаловская

5.40

0.32

27.

Парк Победы

5.40

0.36

63.

Крестовский остров

5.45

0.36

28.

Электросила

5.44

0.33

64.

Старая Деревня

5.43

0.38

29.

Московские ворота

5.45

0.31

65.

Комендантский проспект

5.37

0.03

30.

Фрунзенская

5.48

0.29

Примечание:

Вестибюль Невск.пр-т-2(кан.Гриб.) работает в особом режиме:(с 7:30 до 10:00 и 16:00 до 18:30 - вход закрыт)

Вестибюли Техн.ин-т-1, Пл.Ал.Невского-2 - работают только по рабочим дням.

31.

Технологический институт-1

7.00

20.00

32.

Технологический институт-2

5.40

0.28

33.

Сенная площадь

5.46

0.21

34.

Невский проспект-1

7.00

23.00

35.

Невский проспект-2

5.40

0.23

36.

Горьковская

5.40

0.26

37.

Петроградская

5.38

0.29

1.2. Инфологическая модель

Инфологическая модель применяется после словесного описания предметной области. На основании анализа предметной области выделим следующие сущности модели «сущность-связь» («Entity Relationship» - ER-модели.

Станции

Код станции

Название

Улицы

Код улицы

Название

Код станции

Электрички

Код электрички

Номер

Дата прибытия

Дата отбытия

Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам.

Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов - характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности.

Рассмотрим сущности.

Инфологическое проектирование прежде всего связано с попыткой представления семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить смысл предметной области.

1.3 Даталогическое проектирование базы данных

В реляционных БД даталогическое или логическое проектирование приводит к разработке схемы БД, которая отражает абстрактные объекты предметной области, а также связи (функциональные зависимости) между этими объектами. Некоторые зависимости между атрибутами отношений являются нежелательными из-за побочных эффектов и аномалий, которые они вызывают при модификации БД. При этом под процессом модификации БД мы понимаем внесение новых данных в БД или удаление некоторых данных из БД, а также обновление значений некоторых атрибутов.

Однако этап логического или даталогического проектирования не заканчивается проектированием схемы отношений. В общем случае в результате выполнения этого этапа должны быть получены следующие результирующие документы:

· Описание концептуальной схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности базы данных.

· Разработка процедур поддержки семантической целостности базы данных.

· Однако перед тем как описывать построенную схему в терминах выбранной СУБД, нам надо выстроить эту схему.

· Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.

Разрешение связей типа «многие-ко-многим». Так как в реляционной модели данных поддерживаются между отношениями только связи типа «один-ко-многим», а в ER- модели допустимы связи «многие-ко-многим», то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью допустимых для нее категорий. Это делается введением специального дополнительного отношения, которое связано с каждым исходным связью «один-ко-многим», атрибутами этого отношения являются первичные ключи связываемых отношений. В рассматриваемом примере наблюдаются бинарные связи типа 1:M с обязательным классом принадлежности n-связной сущности и N:M.

1.4 Физическое проектирование базы данных

Физические модели баз данных определяют способы размещения данных в среде хранения и способы доступа к этим данным, которые поддерживаются на физическом уровне. Исторически первыми системами хранения и доступа были файловые структуры и системы управления файлами (СУФ), которые фактически являлись частью операционных систем. СУБД создавала над этими файловыми моделями свою надстройку, которая позволяла организовывать всю совокупность файлов таким образом, чтобы она работала как единое целое и получала централизованное управление от СУБД. Однако непосредственный доступ осуществлялся на уровне файловых команд, которые СУБД использовала при манипулировании всеми файлами, составляющими хранимые данные одной или нескольких баз данных.

Физическая модель БД определяет способ размещения данных на носителях (устройствах внешней памяти), а также способ и средства организации эффективного доступа к ним. Поскольку СУБД функционирует в составе и под управлением операционной системы, и БД размещается обычно на устройствах общего доступа (разделяемый ресурс), используемых самой ОС и другими прикладными программами, то организация хранения данных и доступа к ним в значительной степени зависит от принципов и методов управления данными операционной системы. И, естественно, СУБД в той или иной степени использует не только файловую систему и подсистему ввода-вывода ОС, но и специализированные методы доступа, основанные на тех или иных принципах организации данных.

2. Проектная часть

2.1 Краткая характеристика Microsoft Access

Программное обеспечение для работы с базами данных используется на персональных компьютерах уже довольно давно. К сожалению, эти программы либо были элементарными диспетчерами хранения данных и не имели средств разработки приложений, либо были настолько сложны и трудны, что даже хорошо разбирающиеся в компьютерах люди избегали работать с ними до тех пор, пока не получали полных, ориентированных на пользователя приложений.

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.

Система управления базами данных предоставляет вам возможность контролировать задание структуры и описание своих данных, работу с ними и организацию коллективного пользования этой информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение (задание структуры и описание) данных, обработка данных и управление данными. Все эти функциональные возможности в полной мере реализованы в Microsoft Access. В практике, как правило, необходимо решать и задачи с использованием электронных таблиц и текстовых процессоров. Например, после подсчета или анализа данных необходимо их представить в виде определенной формы или шаблоны. В итоге пользователю приходится комбинировать программные продукты для получения необходимого результата. В этом смысле все существенно упростят возможности, предоставляемые Microsoft Access.

СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.

При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.

Данная СУБД была выбрана по следующим причинам:

§ простота средств реализации,

§ легкость освоения инструментарием разработчика (VBA),

§ наглядность визуализации информации.

Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:

§ загрузка модулей по требованию;

§ оптимизация дерева вызовов;

§ использование файлов MDE;

§ автоматическая поддержка компилированного состояния;

§ использование библиотек Windows API;

§ индивидуальная настройка системы;

§ эффективное использование индексов;

§ встроенный оптимизатор запросов.

Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:

- один-к-одному (одной записи в первой таблице соответствует одна запись во второй);

- один-ко-многим (одной записи в первой таблице соответствует много записей во второй);

- много-к-одному (многим записям в первой таблице соответствует одна запись во второй);

- много-ко-многим (одной записи в первой таблице соответствует много записей во второй и одной записи во второй таблице соответствует много записей в первой).

Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной - если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.

В СУБД Access процесс создания реляционной базы данных включает создание схемы данных. Схема данных наглядно отображает таблицы и связи между ними, а также обеспечивает использование связей при обработке данных. В схеме данных устанавливаются параметры обеспечения целостности связей в базе данных.

Таким образом, осуществляется неразрывная связь внемашинного проектирования базы данных с этапом ее создания с помощью СУБД. В схеме данных, построенной по нормализованной модели данных предметной области, могут быть установлены одно-однозначные и одно-многозначные связи. Для таких связей обеспечивается поддержание целостности взаимосвязанных данных, при которой не допускается наличия в базе данных подчиненной записи без связанной с ней главной, при первоначальной загрузке базы данных и ее корректировках. Связи, определенные в схеме данных, используются автоматически при разработке многотабличных форм, запросов, отчетов, существенно упрощая процесс их конструирования.

2.2 Создание таблиц

Вся информация вводится через экранную форму. Используется следующая условно-постоянная информация.

Для решения поставленной задачи необходимо создать таблицы.

При создании в Access схемы данных в ней определяются и запоминаются связи между таблицами. Это позволяет системе автоматически использовать связи, один раз определенные в схеме данных, при создании форм, запросов, отчетов на основе взаимосвязанных таблиц, а пользователь освобождается от необходимости указывать эти связи при конструировании этих объектов. Схема данных базы графически отображается в своем окне, где таблицы представлены списками полей, а связи - линиями между полями разных таблиц.

Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:

- один-к-одному (одной записи в первой таблице соответствует одна запись во второй);

- один-ко-многим (одной записи в первой таблице соответствует много записей во второй);

- много-к-одному (многим записям в первой таблице соответствует одна запись во второй);

- много-ко-многим (одной записи в первой таблице соответствует много запией во второй и одной записи во второй таблице соответствует много записей в первой).

Вся информация вводится через экранную форму. Используется следующая условно-постоянная информация.

2.3 Создание схемы данных

Создание схемы данных начинается в окне Базы данных (Database) с выполнения команды Сервис|Схема данных (Tools|Relationships) или нажатия кнопки Схема данных (Relationships) на панели инструментов базы данных.

Включение таблиц в схему данных. После нажатия кнопки Схема данных (Relationships) открывается окно Добавление таблицы (Show Table) , в котором можно выбрать таблицы и запросы, включаемые в схему данных. Для размещения таблицы в окне Схема данных (Relationships) надо выделить ее в окне Добавление таблицы (Show Table) и нажать кнопку Добавить (Add). Для выделения нескольких таблиц надо, удерживая клавишу , щелкнуть мышью на каждой из этих таблиц. Включив все нужные таблицы в схему данных, нажать кнопку Закрыть (Close).

В результате в окне Схема данных (Relationships) будут представлены все включенные таблицы со списком своих полей. Далее можно приступать к определению связей между ними.

Связь между таблицами осуществляется ключевым полем ''Код клиента'', которое присутствует в каждой таблице. Связь один-к-одному.

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной из них оказалась модель "сущность-связь" или называемая ещё ER-моделью (от англ. Entity-Relationship, т.е. сущность-связь).

2.4 Создание форм, запросов и отчетов

Для работы с программным продуктом используется простой, интуитивно понятный интерфейс. Последовательность работы с объектами формы определяется доступностью командных кнопок, целостность данных определяется набором используемых в программе проверок.

Формы предназначены для вывода данных на экран в удобном виде, форма может использоваться для поиска данных. Если изъять формы из MS Access, то программа превратится в заурядную СУБД, каких множество. С одной стороны, формы позволяют пользователям вводить данные в таблицы базы данных без непосредственного доступа к самим таблицам. С другой стороны, они позволяют выводить результаты работы запросов не в виде скупых результирующих таблиц, а в виде красиво оформленных форм. В связи с таким разделением существует два вида формирования структуры форм: на основе таблицы и на основе запроса, хотя возможен и комбинированный подход, - это вопрос творчества.

После запуска программы на экране появляется главная форма.

Каждому запросу MS Access можно сопоставить эквивалентную инструкцию SQL. В MS Access пользователи, знакомые с языком SQL, могут использовать его для просмотра и изменения запросов в режиме конструктора, определения свойств форм и отчетов, создания специальных запросов (запросы объединения, запросы к серверу и управляющие запросы), создания подчиненных запросов.

При создании каждого запроса MS Access автоматически составляет эквивалентную ему инструкцию SQL. Изменения, внесенные в инструкцию SQL, автоматически отражаются в бланке конструктора.

Просмотрим или изменим инструкцию SQL:

SELECT Районы.[код района] AS [Районы_код района], Районы.район, Улицы.код, Улицы.[название улицы], Улицы.[код района] AS [Улицы_код района]

FROM Районы INNER JOIN Улицы ON Районы.[код района] = Улицы.[код района];

Для вывода на печать документов на основе данных из базы используются отчеты. Отчеты во многом похожи на формы, но имеют иное функциональное назначение - они служат для форматированного вывода данных на печатающие устройства и, соответственно, при этом должны учитывать параметры принтера и параметры используемой бумаги.

Заключение

В общем смысле термин «база данных» (БД) можно применить к любой совокупности связанной информации, объединенной вместе по определенному признаку, т.е. к набору данных, организованных определенным образом. При этом большинство БД использует табличный способ преставления, где данные располагаются по строкам (которые называются записями) и столбцам (которые называются полями), причем все записи должны состоять из одинаковых полей и все данные одного поля должны иметь один тип. Например, расписание движения поездов, полетов самолетов, книга заказов или учет товаров и т.п. легко могут быть представлены в такой форме. Базы данных должны содержать только независимую (первичную) информацию, поэтому не любая таблица представляет собой базу данных.

В последнее время наибольшее распространение получили реляционные базы данных (слово «реляционная» происходит от английского relation - отношение). Концепции реляционной модели данных связаны с именем известного специалиста в области систем 6aз данных Е. Кодда. Именно поэтому реляционную модель данных в литературе часто называют моделью Кодда.

В компьютерном варианте в реляционной БД информация хранится, как правило, в нескольких таблицах-файлах, связанных между собой посредством одного или нескольких совпадающих в этих таблицах полей (в некоторых компьютерных системах все таблицы одной базы помещаются в один файл). Каждая строка в таблице реляционной БД должна быть уникальна (т.е. не должно быть одинаковых строк-записей). Такие уникальные столбцы (или уникальные группы столбцов), используемые, чтобы идентифицировать каждую строку и хранить все строки отдельно, называются первичными ключами таблицы.

Первичные ключи таблицы важный элемент в структуре базы данных. Они - основа системы записи в файл и, когда необходимо найти определенную строку в таблице, то ссылаются к этому первичному ключу. Кроме того, первичные ключи гарантируют, что данные имеют определенную целостность. Если первичный ключ правильно используется и поддерживается, то можно быть уверенным, что нет пустых строк таблицы и, что каждая строка отличается от любой другой строки.

Основным назначением БД является быстрый поиск содержащейся в ней информации. При этом БД могут содержать значительный объем информации, например, список домашних телефонов г.Астрахани (с его недостаточной степенью телефонизации) составляет десятки тысяч абонентов. В телефонной книге абоненты упорядочены (отсортированы) в алфавитном порядке и поиск по фамилии займет не очень много времени, однако, поиск по адресу или неточному номеру телефона и т.п. вручную - не решаемая практически задача.

Мир баз данных становится все более и более единым, с развитием Internet- и Intranet- технологий появилась возможность доступа к удаленным БД, что привело к необходимости создания стандартного языка, который мог бы использоваться так, чтобы функционировать в большом количестве различных видов компьютерных сред. Стандартный язык позволил бы пользователям, знающим один набор команд, использовать их, чтобы создавать, отыскивать, изменять и передавать информацию независимо от того, работают ли они на персональном компьютере, сетевой рабочей станции или на универсальном компьютере.

Список литературы

1. Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 320 с.

2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1989. - 351 с.

3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.

4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. - 252 с.

5. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.

6. Кириллов В.В. Структуризованный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.

7. Корнеев И.К., Машурцов В.А. Информационные технологии в управлении. - М.: ИНФРА-М, 2001. - 158 с.

8. Мартин Дж. Планирование развития автоматизированных систем. - М.: Финансы и статистика, 1984. - 196 с.

9. Хаббард Дж. Автоматизированное проектирование баз данных. - М.: Мир, 1984. - 294 с.


Подобные документы

  • Цель инфологического моделирования предметной области. Источники данных, базы данных и система управления, разработка модели. Принципы проектирования базы данных, концептуальная, логическая, материальная разработка. Типы сущностей, атрибутов и связей.

    курсовая работа [188,6 K], добавлен 15.07.2012

  • База данных - это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Классификация баз данных. Использование СУБД Microsoft Access для создания баз данных: особенности и функциональные возможности программы.

    реферат [623,6 K], добавлен 22.05.2008

  • Microsoft Access как система управления базами данных (СУБД), ее предназначение. Организованная структура для хранения данных. Типы данных при работе с Microsoft Access 2003 и Microsoft Access 2007. Проектирование баз данных и построение ER-диаграммы.

    контрольная работа [16,3 K], добавлен 10.10.2010

  • Характеристика сущностей инфологической модели и проектирование модели базы данных технологического процесса. Описание предметной области и основы инфологического моделирования. Особенности проектирования и обеспечение выполнения объявленных функций.

    курсовая работа [22,5 K], добавлен 27.02.2009

  • Теоретические аспекты проектирования баз данных. Определение предметной области информационной системы, этапы ее проектирования. Особенности инфологического и даталогического видов проектирования. Реализация проекта в среде SQL Server Enterprise Manager.

    курсовая работа [511,8 K], добавлен 11.03.2014

  • Основные понятия баз данных: нормализация, связи и ключи. Создание и этапы проектирования базы данных, решение задачи о предметной области. Изучение СУБД Microsoft Access s 2003: пользовательский интерфейс, главное окно приложения, создание таблиц.

    реферат [2,1 M], добавлен 10.11.2010

  • Теоретические основы работы с Microsoft Access 2007. Основные принципы проектирования баз данных. Начало работы с Access 2007. Особенности создания базы данных Книжный магазин. Создание формы с помощью инструмента "Форма". Мастер отчетов: авторы, книги.

    курсовая работа [4,9 M], добавлен 05.10.2011

  • Краткая характеристика и функциональные возможности MS Access. Базы данных и системы управления базами данных. Проектирование в теории и создание на практике базы данных в продукте корпорации Microsoft для управления базами данных "Microsoft Access".

    курсовая работа [1,6 M], добавлен 07.03.2015

  • Построение инфологической концептуальной модели предметной области. Структура базы данных Microsoft Office Access. Формы, запросы и отчеты. Создание форм, запросов и отчетов в базах данных. Схема данных физической и логической сущности в Erwin 4.0.

    курсовая работа [5,1 M], добавлен 13.12.2011

  • Характеристика современных информационных систем. Структура Microsoft Access 97, его справочная система, типы данных, особенности использования, ввод, редактирование и просмотр данных. Создание новой базы данных с помощью Конструктора в MS Access 97.

    реферат [49,1 K], добавлен 23.10.2009

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.