DEV Community: QuantumSink

Normality for a Flexible World

QuantumSink — Mon, 28 Sep 2020 02:30:39 +0000

It might be contradictory to view both normality and flexibility in the same vein, but we look to normality in database design to create flexible change. Besides, the idea of normality is a lot like nesting if statements. If you know what those are, anyway. If not, then here's a quick rundown of the first two normal forms:

First Normal Form:

We want to make sure that the data we present is necessary to have separately. For instance, look at this table.

First, let us ask if our table has a primary key.
Well, I wouldn't really get far without making one after the diagrams I've already shown, so yes, we have established "BehaviorID" as a primary key.

Are any columns able to be represented as two other columns?
I would say so. Instances can certainly arise in a messy setup, such as design a column to contain more than one piece of info, but most of the time, I would say you would recognize an issue like this immediately. Always make sure that a column is made to contain one type of data.

Then, finally, do any columns repeat their groups?
Not at all! We can safely establish this table as First Normal Form.

Second Normal Form:

To constitute a Second Normal Form, we need to keep all the components of First Normal in check. Then, we examine whether or not all columns refer to the primary key of the table. If anything could be representing something that isn't the primary key, it's likely that that data can be represented as a different entity (table) in the database.

Take this table for instance. As the OccupationName may relate to the CompanyID, all other columns can be related to the OccupationName, not the CompanyID. Thus, we must delegate that information into a new table by altering this one, then creating a new table to represent Occupations.

And yet, how will we do that? Watch the two videos below, and we'll get into how we ALTER tables in SQL, and have a live look at "Normality".

The Aura App & Physical ERD's: Getting Things in Order

QuantumSink — Mon, 14 Sep 2020 02:41:21 +0000

And in the case of Albion College, maybe a bit too in order. Law and chaos are two sides of a glass coin, and trying to flip things onto either side can be a mess. It's never to say a balance is always best, surely freedoms must be found in certain places, and places where law must control things to keep the peace. Albion's "Aura" app, which tracked the locations of "COVID-Positive students" to trace who those students have made contact with, landed flat on the law. Students had to adhere strictly to the guidelines provided by the university and neglect of the app's use would result in disciplinary action.

Now, I'm not saying keeping a constant trace on students' locations is a BAD idea but...

No. No it's pretty bad.

At least, it certainly wasn't necessary. Before I start rattling off alternatives, any sort of app that puts this kind of grip on people is going to come with its backlash, and is going to need justification. And before all that, it needs to be SECURE.

Having keys, granting access to all sorts of student data, right in the source code is not my idea of "secure". In fact, why even store that much about the students to begin with? Keep in mind again that this was all mandatory as well: you're giving an app access to your student info. Because you have to.

...Just, look.

No one wants to spread a deadly disease. But no one wants to live under constant monitoring, their location always on and traceable. It's the kind of stuff you see in movies about dystopias.

Wait. Oh right. We're in one at the moment. I guess this makes sense then.

But we shouldn't have to worry about both COVID and an app, of all things. We're all human, and we all (at least, a large majority of us) care about the lives of other humans. And also ourselves. If we're going to understand who has made contact with who, there should just be a voluntary submission, maybe weekly, of who that person has made contact with in the past week. That puts a lot of faith in memory, but it's better than putting faith in pushing private data into an app. There's always middle roads to find: but landing exactly on the edge of that glass coin is near impossible. We just have to keep finding ways to balance that out.

This time around, we'll be delving into some modified versions of the COVID diagram from last time, and assessing another possible way to map an app. This will access how one would handle an app that inquires a person's risk of catching COVID-19. It's always a good thing to try to be aware, and awareness is what helps keep viruses at bay.

Conceptual

Physical

I'll leave off with a quote that I wish those older than preschoolers would take to heart as well:
"If you can't cure it, the only option is to keep it from spreading... Even a preschooler knows that."
--- Hiyoko Saionji from Super Danganronpa 2: Goodbye Despair

Sources:

Where We Are: Mapping Our Dystopia

QuantumSink — Mon, 07 Sep 2020 00:32:17 +0000

Hey.

See that? It's a diagram! An entity relationship diagram. Wow. Well, thanks for checking it out, I'll...

Okay. Okay, yeah, I'll explain.

This diagram exists to help map out the relationships between several components that are related to the COVID-19 crisis. It's a great visual for understanding the basis of an SQL database as well. We use these diagrams to see what acts on what, what attributes does what have, and how much of what is acting on what.

What.

In a database, these connections exist to help relate entities, and each entity can be used to represent what may be a table of data in an SQL database. A primary use would be to understand... well, primary keys. Keys are used to identify each unique tuple (row) in a data table. After all, if all the data started looking the same, it would be hard to understand what you were looking at. Primary keys ensure that the data for each tuple is meaningful.

If any of these terms are starting to sound foreign, then no worries, foreign keys exist too.

I'm sorry.

You'll see these keys as attributes (columns) assigned to one entity, and their relation back to a primary key from another entity.

Keys are the heart of connections for SQL, and in these next two videos, we'll discuss these topics and how they're stored, connected, and understood in an SQL world, and maybe, you'll find your place in this crazy world of reality as well.

With all that said, you can throw yourself in and think: Where am I, in this world of risks? Would my behavior correlate to them? There's plenty of connections all around, and you can be a key part of someone else's world. You can represent a part of this dystopia. But don't see yourself as a patient, and definitely don't try to become one. Just realize that this isn't an isolated world. We're in this together.

We'll be delving back into this diagram next time, and I hope you all stay safe out there: the risks aren't as bad as long as you know how to keep yourself safe.

Sources:

Mapping Out (Less than 1% of) the World

QuantumSink — Sun, 30 Aug 2020 19:57:47 +0000

Hey there, thanks for taking a look at the thoughts I'm letting flow into this drain I call a blog post. In truth, I'm just your average college sophomore at Penn State University Park, majoring in Data Science.

Okay, I have more of a life than what a title like that implies. I've been interested in several fields as a kid, like game development, psychology, and writing. In high school, I took an AP Statistics class as a sort of "well, why not" kind of thing, just to have more AP credit.

In the end, I realized how being able to use statistics to understand more about the world around us was actually fascinating. It's how we both document and predict events that happen. So where does that leave me now?

Learning about databases to make use of this data
Secretary of the Penn State Pokemon Society
Looking to minor in Psychology
Writing the blog post right now

So, in a way, I guess all those ambitions found me, one way or another. Hm.

Now that you know a bit about those ambitions, let's talk about the ambition I have to show you how Diagram.net works. Probably like, on a scale of 1 to 10, I'm at a 7 today? That's better than average. In any case, I'll be showing how to quickly produce a flowchart of decisions and paths, along with a small bit about how we can use a diagram representation to explain the differences of SQL and NoSQL.

Of course, what I showed of SQL and NoSQL is just a small facet of their structure, and we won't be going in full depth on it quite yet, but as this is an IST class, I felt as though showing off diagrams.net would not suffice on its own.

The main takeaway to this is that diagrams.net is a great tool for structuring your pathing and data, as using and modifying directional arrows is often useful when you want to explain what relates to what in an SQL structure, but in NoSQL's more document by document representation, such relations must be made manually. Ultimately, both diagrams display the same data, but the structural differences derive from those connected/unconnected relations.

In SQL, it would be simple to create an line from an ID and then point at where it lies in a different table, and it simply means that whatever is represented inside that ID can be represented in that table by its ID number. The path from a "Shoe ID" to a "Pair ID" in a NoSQL world would require its data to be shown in the "Pair ID" as well, not just by its number. Diagrams.net can be used to represent both, either with connected cells to explain SQL data or cells spaced out to represent NoSQL data.

I hope that this entry will help you understand the basic features behind diagrams.net, and how simple it is to edit and create diagrams to explain your own concepts. Good luck to all my peers, and I'll see you in the next post.

Sources:

diagrams.net
SQL vs NoSQL or MySQL vs MongoDB by Academind: https://www.youtube.com/watch?v=ZS_kXvOeQ5Y
SQL vs NoSQL: Which one is better to use? by Geeks for Geeks: https://www.geeksforgeeks.org/sql-vs-nosql-which-one-is-better-to-use/