Это нам кажется, что понимать нечего. Люди, которых никогда ничему подобному не учили, не знакомы с моделированием и алгоритмами как концепцией. По крайней мере, студенты-андерграды. У меня там дальше в курсе data flowcharts, их, по опыту, осваивает около 20% студентов. То есть, я им все равно покажу ERD, но совсем примитивную, уберу с нее все, что можно.
я недавно сыну объясняла. Начала с того, зачем это нужно. Привела пример, вроде банка, где важны определенные вещи => normalization. А потом уже про ERD
Слайд №1 - объяснение таблиц (relations), как совокупности одинаковых описаний (attributes) однотипных объектов (tuples). Если они уже проходили OOD, то уместно провести аналогию - не на слайде, конечно, а устно. Если допустимо сделать динамические слайды, то я бы начал с объекта для примера, описания его атрибутов в виде заголовка таблицы, а потом добавил по очереди 1-2-3 строки. Обязательно упомянуть о том, что термин relation изначально подразумевал логическую связь между соединяемыми вместе записями: один тип объекта, одинаковое описание. Слайд №2 - объяснение связей между объектами-таблицами. Тут, думаю, тебе подсказки не нужны. Обязательно упомянуть, что в современном датабейзостроении термин relation подразумевает именно связи между таблицами.
Ха!! Ха!!! Ха-ха-ха!!! Они "уже" проходили OOD!!!!! Пацталом. Они бухгалтеры, Володя! На третьем курсе! Я базы данных отдельным классом читала два раза. Но даже в слайдах для того отдельного класса не могу найти хорошего примера, чтобы вот за пять минут и на пальцах. Придется, наверное, самой рисовать, а лень. :)
Бухгалтеры?! Так это ж в 1000 раз проще! Суть слайдов остается та же: 1й слайд - таблицы, 2й - связи. С таблицами бухгалтеры уже знакомы в принципе, они всё время работают с таблицами, нужно только выбрать пример из их области и объяснить терминологию. Понимание связи между таблицами у них тоже должно быть, хоть и интуитивное. Возьми для примера таблицы из микрософтовского Northwind. Скажем, Orders и Order Details. Хотя, конечно, придется дорисовать тексты с терминологией и стрелки. ;^)
P.S. Хмм... Прочитал коммент Паровоза и засомневался: я, похоже, должен был знать, что ты читаешь бухгалтерам, но почему-то совсем-совсем этого не помню. Йа блондинко?
P.P.S. И - самое главное! - при объяснении БД бухгалтерам ни в коем случае не вдаваться в теорию реляционных БД и не показывать никаких абстракций вроде ERD. Объясняй только на живом примере.
Может, на примере телефонной записной книжки рассказать? Есть отсортированная "таблица" с двумя колонками и отношение между двумя колонками. Можно добавлять и удалять записи, можно искать телефон по имени (быстро, потому что есть индекс) или имя по телефону (медленно, потому что нет индекса). P.S. Володя с OOD порадовал :)
Может быть "родители и дети"? Нарисовать семью и чтобы одну и ту же информацию не писать для каждого человека, просто "ссылка" на его родителей. Вот такие связи :-)
мне надо болеебизнес-пример. В общем, мне надоело над этим голову ломать, я плюхнула на слайды пару примеров, посмотрим, насколько они окажутся полезными.
кхм... а зачем два слайда? Одного слайда с табличкой не хватит? Связи между таблицами - это уже лишнее. База из одной таблицы - вполне relational database. A, на втором слайде можно привести примеры non-relational баз.
А все эти ERD и прочие гадости оставь для тех, кому это потом надо будет. Среди бухов их нет.
так это и есть правильно. Тебе-же не надо им объяснять методы оптимизации запросов и прочую галиматью им не нужную. Тебе надо, чтоб они не пугались такого словосочетания и примерно представляли о чем речь.
Да, именно экселевская табличка. В крайнем случае - несколько табличек в одном workbook. И фсё. Большего не надо.
Ну с учетом того, что моя задача - объяснить им, чем отличается реляционная база от экселевской таблицы, пожалуй, только экселевской таблицы будет недостаточно :)
В экселе ничего не запрещали, но почему-то большие интегрированные системы предпочитают данные в других форматах. Достоинства я продаю студентам исключительно теоретические :)
Первый слайд - книга приход-расход, тут же бух.проводки и сведение баланса. Основная мысль - ничто не должно пропадать. Второй слайд - в компьютере за это отвечает СУБД, где данные хранят в таблицах. Вот как выглядят таблицы для предыдущего слайда - просто часть данных в колонках, но с показом связей. СУЮД отвечает за то, чтобы в проводки не попало что попало, чтоб были только счета из плана счетов, чтобы сумма была положительная и прочие вкусности. Основная мысль - с помощью этой штуки БАЛАНС СОЙДЕТСЯ ВСЕГДА!
Помню когда мы внедряли бух.систему в отделении Лукойла, внедренец рассказывал как он девочку-бухгалтера обучал вбивать первичные документы. Она очень была недовольна, ворчала, что ей еще журнал сводить. Тут он сорвал ей шаблон, заявив, что не нужно ничего сводить и ПОКАЗАЛ, что он получается просто выводом нужного отчета.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Но подозреваю, что все равно этим кончится.
no subject
Там же квадратики с понятными названиями.
Типа: (person) -< (order) >- (product)
Пример:
"Joe Shmoe" -< 1 >- < Big Mac >
-< 2 >- < Fries >
no subject
То есть, я им все равно покажу ERD, но совсем примитивную, уберу с нее все, что можно.
no subject
no subject
no subject
Слайд №2 - объяснение связей между объектами-таблицами. Тут, думаю, тебе подсказки не нужны. Обязательно упомянуть, что в современном датабейзостроении термин relation подразумевает именно связи между таблицами.
Как-то так. Если что - расспрашивай.
no subject
Я базы данных отдельным классом читала два раза. Но даже в слайдах для того отдельного класса не могу найти хорошего примера, чтобы вот за пять минут и на пальцах. Придется, наверное, самой рисовать, а лень. :)
no subject
Суть слайдов остается та же: 1й слайд - таблицы, 2й - связи. С таблицами бухгалтеры уже знакомы в принципе, они всё время работают с таблицами, нужно только выбрать пример из их области и объяснить терминологию. Понимание связи между таблицами у них тоже должно быть, хоть и интуитивное.
Возьми для примера таблицы из микрософтовского Northwind. Скажем, Orders и Order Details. Хотя, конечно, придется дорисовать тексты с терминологией и стрелки. ;^)
no subject
Йа блондинко?
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Связи между таблицами - это уже лишнее. База из одной таблицы - вполне relational database.
A, на втором слайде можно привести примеры non-relational баз.
А все эти ERD и прочие гадости оставь для тех, кому это потом надо будет. Среди бухов их нет.
no subject
no subject
Тебе-же не надо им объяснять методы оптимизации запросов и прочую галиматью им не нужную. Тебе надо, чтоб они не пугались такого словосочетания и примерно представляли о чем речь.
Да, именно экселевская табличка. В крайнем случае - несколько табличек в одном workbook. И фсё. Большего не надо.
no subject
no subject
Без ухода в дебри внутреннего устройства, оптимизации, планировщика и прочей гадости.
Как насчет краткой версии в воскресенье? Под водочку. Можно без слайдов :)
no subject
no subject
А то, что этим мало кто пользуется - таки и базы реальные тоже обычно спроектированы левой ногой. Но это не умаляет их теоретических достоинств.
no subject
no subject
Ну и привычка, конечно.
no subject
no subject
Второй слайд - в компьютере за это отвечает СУБД, где данные хранят в таблицах. Вот как выглядят таблицы для предыдущего слайда - просто часть данных в колонках, но с показом связей. СУЮД отвечает за то, чтобы в проводки не попало что попало, чтоб были только счета из плана счетов, чтобы сумма была положительная и прочие вкусности. Основная мысль - с помощью этой штуки БАЛАНС СОЙДЕТСЯ ВСЕГДА!
Помню когда мы внедряли бух.систему в отделении Лукойла, внедренец рассказывал как он девочку-бухгалтера обучал вбивать первичные документы. Она очень была недовольна, ворчала, что ей еще журнал сводить. Тут он сорвал ей шаблон, заявив, что не нужно ничего сводить и ПОКАЗАЛ, что он получается просто выводом нужного отчета.