Урок 18. Создание реляционной БД

Привет.

С Вами Веселов Александр.

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

- А какие данные удобно и нужно помещать в базу? - спросит меня пытливый читатель и будет прав, подумав: "Неужели, нельзя обойтись электронной таблицей типа Excel?"

Я не скажу в ответ "нет". Вообще, как аксиому, советую принять во внимание следующее: "Для решения той или иной компьютерной задачи, как правило, существует несколько способов". А посему - обойтись-то можно, НО!

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

1. Принцип. Любую информацию, которую можно упорядочить и представить в виде пронумерованного списка (списков), удобнее хранить в базе данных.
2. Принцип. Для информации, которую можно выделить по определенному признаку (или набору признаков) должна быть организована отдельная таблица в базе данных.
3. Принцип. Никакие данные не должны дублировать друг друга (иными словами: каждая цифра должна храниться один раз).

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

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

допустим, имеются два списка (таблицы): первый список содержит фамилии сотрудников, второй - зарплату за текущий месяц.

На бумаге (или в Excel) это выглядело бы так:

Таблица 1 - список сотрудников организации:

1. Иванов
2. Петров
3. Сидоров

Таблица 2 - зарплата за текущий месяц:

1. Петров   30000 р.
2. Сидоров 20000 р.

(а Иванов ничего не заработал :-) в этом месяце).

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

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

1. 2    30000 р.
2. 3   20000 р.

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

3.  4   100 р.,

потому что в первой таблице нет фамилии под номером 4.

Далее, предположим, что Петров уволился с работы. Мы удаляем его фамилию из первой таблицы. Реляционное отношение, установленное между таблицами, не даст нам этого сделать просто так. Ведь, удалив фамилию из списка первой таблицы, нарушится все тот же принцип №3! Поэтому, база данных, в зависимости от того, как мы настроим свойства реляции, либо

• удалит всю информацию про Петрова (т.е. строчку 1.   2    30000 р.) из второй таблицы (так называемое каскадное удаление данных)
• либо предложит нам оставить все как есть (тогда проектировщик базы данных должен сам позаботиться о том, чтобы как-то пометить запись про Петрова, чтобы он больше не попадался на глаза в будущем), выдав на экран сообщение о невозможности удаления записи из первой таблицы, так как имеются связанные реляцией записи во второй таблице.

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

Что ж, приступим, наконец, с Божей помощью.

Тем, у кого установлен Microsoft Office, нужно открыть программу MS Access: файл - создать - новая база данных - дать имя файлу "Rashod" и нажать кнопку "Создать".

Далее нужно нажать "Создание таблицы в режиме конструктора".

Ниже на примере показано, как в конструкторе создана таблица Main, какие она содержит поля, каких типов эти поля:




Обратите внимание, что поле ID содержит уникальную нумерацию, организовывается такое поле путем нажатия пиктограммы ключа. Обычно такое поле имеет тип целочисленный  "счетчик", т.е. автоматически увеличивает свое содержимое на 1 при добавлении новой записи. Уникальность значений в этом поле обуславливается свойством "Индексированное поле", в котором указано, что совпадения не допускаются.

Позже Вы установите для себя, что действительно в таком поле значения уникальны. Предположим, что Вам все же удалось удалить Петрова из таблицы 1, поле "ID" которой организовано как счетчик с уникальными значениями. Тогда после добавления новой записи, значение поля ID никогда уже не станет равным 2. Новая фамилия будет добавлена в строчку под номером 4, и значение ID=2 никогда уже не появится в таблице 1.

Для программы "Расходы" нужно создать базу данных из следующих таблиц:

Все таблицы в зависимости от их назначения можно разделить на четыре типа:

1. Кодификаторы (или справочники) - это таблицы Accounts, Credits, ExpenseGroup, MOs, Val, которые представляют из себя зачастую простые списки по типу Таблицы 1, описанной выше. Они постоянно хранят ту информацию, для которой предназначены.
2. Корреляционные (вспомогательные). Корреляционная таблица постоянно хранит взаимосвязь данных из других таблиц (как правило - справочников). К таким таблицам относится ExpenseAcc. Эта таблица не хранит никакой основной информации (а основной информацией в учете являются записи, отражающие хозяйственную деятельность, т.е. проводки), а лишь указывает к какой группе счетов относится тот или иной счет.
3. Временные (вспомогательные).  Временные таблицы нужны для временного хранения результатов каких либо расчетов. Это таблица Oborot. Как Вы увидите ниже, я даже не включил эту таблицу в схему данных, так как временная таблица может не иметь реляций с другими таблицами. Она их и не имеет.
4. Главные (основные) таблицы. Эти таблицы хранят постоянно всю необходимую информацию. Прообраз главной таблицы из примера, приведенного выше - это Таблица 2. А в базе данных "Rashod.mdb" такая таблица одна и называется она Main.

На рисунке ниже я показал структуру базы данных

Как видно, в структуре присутствуют и объединены связями все таблицы, кроме временной.

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

На этом сегодня все. Если у кого-то остались вопросы, а я прекрасно понимаю, что в рамках такого короткого урока я только дал основные направления, прошу написать мне любым доступным способом.

Наглядный видео урок Вы можете посмотреть или скачать.

Что же дальше?
Любая программа должна начинаться с заставки, но лучше, если есть возможность эту заставку отключать.